Programming Methods
Programming Strategies Imagine this situation: The build season is coming to a close. The builders are racing to scrap together a ball intake that actually works and you still haven't had time to sit down with the robot to write your code. The stress is mounting and then suddenly some mentor or head builder plops the (almost) completed robot down in front of you and says, "OK, let's see autonomous". It's a programmer's worst nightmare (or second worst, we'll get to the worst one later). Don't let this happen to you; you have to start coding before the robot is done. On this team, that's not much of a problem because a lot of our testing is done with speed controllers which have to be programmed before the whole robot is done. While it is very important to have the programming done before the robot is done, it is also important that there is ample time to test all the sensors, autonomous, and everything else, while still having enough time for driving practice. Here's what you can do before the full robot is accessible to the programmer: 1. Discuss: At the beginning of the season it's important to figure out how the robot should be programmed to best implement the strategy that the team has chosen to pursue. This includes questions like: * What kind of drive method should we use? * What joysticks should we use? * What are our subsystems? How should the interact with each other? * What should we do during autonomous? * What sensors should we have and where should they be used? * Where might vision processing be useful if not necessary? * Where should we put a camera and how many of them should we have? * etc. These discussions should give a good sense of how difficult it will be to program specific parts of the robot and are a good indicator of how much energy should be spent programming. For example, shooting a small ball into a small goal (like in Steamworks) could necessitate some sort of vision processing to align with a goal while shooting a ball into a wide goal like in Aerial Assist might not require such vision processing. 2. Plan: Once you know what needs to be programmed, the code should be planned out. I prefer flowcharts as they provide a nice hierarchy to work with. If using object oriented programming, each relationship ("IS A", "HAS A") should be clearly marked as should what methods each component calls and where they are called. It's a lot, but it will make it much more simpler to code. If you just start coding you're going to end up commenting out a bunch of stuff that you thought you were going to use but ended up not needing (see Steamworks code as an example of this…). Here is this year's flowchart: In addition to mapping out the interactions that will take place during the match also sequentially map out what should happen during each autonomous. In addition to illuminating the path to successfully coding the robot, a flow chart looks great if it's stuck in an engineering notebook ;) 3. Pseudo code The whole robot should be pseudocoded before writing actual java (or whatever language you're going to be using). This would provide a higher-level overview of how the robot works. This can be done in a normal word processing application (I'd recommend Docs for the collaboration aspect). There are all sorts of standards for pseudocode and I'll discuss one below with some examples, but you don't have to use this particular style. The two most important things are that (1) there is some standard, and (2) all the logic behind the code is flushed out. It should be very easy to translate the code from final pseudocode to actual robot code. This is similar to planning but more formal. Here you're going to put your plan into the sequential steps that need to be performed. Start at a high level with just the framework. Create separate files or pages for each class that you need and identify any inheritance or polymorphic relationships between classes. This initial framework might include the method headers, but not the logic the methods need to contain. The next step is to flush out all the necessary logic. It is important at this stage to become familiar with the wpilib API which might have some of the logic already implemented. These API methods can be used as black boxes. I will include examples of this process in the appendix. Pseudocode Standards (adopted from http://users.csc.calpoly.edu/~jdalbey/SWE/pdl_std.html, which seems like a reputable source...): * Always be as explicit as possible. Someone else (i.e. Mrs. Zinn) should be able to read your pseudocode and translate it. Vague pseudocode is useless. ** Example: Write "OBTAIN autonomous mode selected on driver station" instead of "SET auto to get selected auto" * Use Keywords when appropriate. These help with the translation ** For loops: FOR, WHILE, DO...UNTIL for loops ** For conditions (DON'T USE CASE!!!): IF...THEN...ELSE, CASE ** For getting values: READ, OBTAIN, GET ** For setting values: SET, INIT ** For mathematical operations: CALCULATE, SUM, MULTIPLY, INCREMENT ** For displaying values: PRINT, OUTPUT, DISPLAY ** For calling methods: CALL I know all this seems like a bit of overkill, but it's really important to organize your thinking before you start to code. (Not to mention it's something nice to show judges). I'll include some example pseudocode at the end. 4. Set Up for Prototyping: Using whatever language/IDE you want to program the robot with (more on that later) create a robot project. I'd recommend at first having separate projects for testing prototypes and for the final robot. The prototype testing project will have to be modified often and might not have much to do with the actual code (for example, the motor speeds or joystick buttons might be off). It would create a playground environment for messing around with prototypes. This could include anything from running a first attempt at a shooter to messing around with vision processing or feedback loop constants. Everything that works can be transferred over to the robot project file after testing the prototypes. If something works in the prototyping, move it into the final project file. Organize everything the way it is organized in the plan, and make sure everything you add is a direct translation of final pseudocode. Don't worry so much about the specific values of motor speeds, port identifiers, or vision processing constants; just keep track of what needs to be calibrated when you actually have the robot. Outline what will happen in autonomous (again don't worry about the specific values). For example write: public void autoPlaceGearAndShoot() { driveStraightSide(); turnSixtyRight(); driveStraightGear(); dropGear(); backOffPeg(); lineUpShooter(); shoot(); } (If the robot is placing the gear on the left peg in autonomous and then shooting) 5. Testing the Robot Code without the robot: This is another level of programming and will be further discussed in a later section. Basically, if the robot is supposed to take certain actions under certain conditions, the initial conditions can be simulated so ensure that the correct actions are taken. These tests can be automated to identify logic errors. Coding with multiple people: One of the challenges of robotics programming is getting everyone who wants to be involved. There are a few strategies that can be followed to involve everyone: * The pseudocoding can be done on a platform like google docs so multiple people can work on the pseudocode at the same time. * Use more than one computer. We have two computers that can be used to work at the same time. Both can be fork the same github project to work simultaneously. Choosing a Language Listing out all the languages used to write robot code isn't to monstrous a task. A lot are easy to pick up with a simple tutorial Be careful which one you choose so the level is right for you View all the resources available. Some teams put out their own programming tutorials If you're still having trouble deciding roll a die or flip a coin Even if you choose one that you end up not liking, it's usually quite easy to switch When you make a decision make sure that anyone involved with programming knows Sometimes someone will point out an effect that has gone unnoticed Unless you really like one language over another, the choice doesn't matter Coding is really a matter of personal preference and whatever makes you comfortable Kicking yourself over choosing the wrong language is a waste of time Seems like you're ready to start coding… There are four languages mainly used in FRC robotics programming: * Labview * C++ * Java *Python Category:Tutorial